Software Engineers as Artisans
A bridge between two mindsets
‘Anyone can build a bridge that stands, but it takes an engineer to build a bridge that barely stands.’
This quote must be one of the most repeated in the engineering world. Far from speaking about the quality of bridges built by engineers, it refers to the capability of sticking to budgets in the engineering world and the ingenious solutions we engineers can bring to the table when facing a real-world problem. Anyone with an unlimited budget can pile up rocks between two cliffs and call it a bridge. It is when you are given limited resources that the difficulty skyrockets.
If you propose building a bridge with particular parameters to a number of civil engineers, most of them will come up with a similar solution: a similar number of pillars, amount of material, and if you are lucky, even expected construction time. The same could not be said about a software project, and this is what I want to talk about today. Because software engineering may very well be the most artisanal of all the areas of engineering, with all the good and bad connotations that come attached to this term.
On the negative side, artisanal products sometimes lack consistency — and while we like them having their own quirks, it’s not what typically we look for in software. On the bright side, a good artisan aspires to become a true master of their craft, keeping their tools sharp and improving the way they work to get the best results. This path to mastering the craft led to the Software Craftsmanship Manifesto, created in 2009 and inspired by the Agile Manifesto.
Having artisans in your development team is critical for developing great software products, but so is having an engineering mindset. In the same way that a civil engineer tests the materials for a bridge, a Software Engineer must be able to assess the quality of the project they are working on and be able to adapt when they face unexpected difficulties. Having a set of solutions that have previously worked when solving a problem is really useful, but even more useful is being able to review in retrospect what could be improved in these solutions. Ultimately, it’s having an open mind to find a new approach when the chance appears again.
The last deciding factor of a good software engineer is being able to stick to a budget. This is a bit more abstract because the budget is something a software engineer manages in their own time. And don’t get me wrong, everybody likes developing great features and the satisfaction that comes from showing them in action. But one of the main pitfalls that software engineering teams fall into over and over again is overengineering and delivering more complex functionalities than they are asked for.
This effort can lead to a tough situation, because the decision would be removing this code from the project and basically wasting the time invested. Or you could keep it assuming the cost of maintenance that will come attached, just in case you will need it in a future that may never come. The worst outcome of all is going over budget and a product with great potential may end up failing. This has an obvious side effect in the economic loss for the company, but also a not so obvious one — in dragging down the team’s morale after not achieving the goal.
As the software industry evolves and matures, awareness around these engineering and artisan mindsets will be key in successful teams and companies. So enjoy the ride, sharpen your engineering skills and become a master of your craft.
Curious about how we do this at Empathy.co? Consider joining our teams.
